A growing sector of computer systems is that of cloud computing. Cloud computing is a general term that refers to any computer system delivering hosted services over the Internet. These services include at least so called Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS).
IaaS normally allows the developer to run any kind of application as long as it is bundled in a certain way. Normally, this means Virtual Machines (VMs), but more recently containers, such as provided by Docker which are discussed in more detail below, have been used as an alternative to VM.
A known IaaS is Amazon Web Services, which provides the developers, or end-users, with virtual server instances and storage, as well as application program interfaces (APIs) that allow the developers to start, stop, access and configure virtual servers and storage as required by their needs.
There exists a wide range of known PaaS. In the context of the cloud, PaaS is defined as a set of software development tools hosted on a provider's infrastructure, even an IaaS as above. Developers create applications on the provider's platform over the Internet. PaaS providers may use APIs, website portals or gateway software installed on the customer's computer. GoogleApps is a well-known example of PaaS.
Furthermore, concerning PaaS, computer systems is often a core function of a service, or function, of a complex system, like a business system, sales system, warehouse system, package tracking system etc.
A special kind of platforms for hosting such systems are provided as services. Thus, this kind of special platforms is often referred to as Platform-as-a-Service platforms (PaaS platform).
PaaS is a cloud platform that provides functionality to develop and deploy applications, for example providing support to provision and host databases, scale applications, or automatically restart broken software components. The applications and databases may constitute the backbone for the complex systems mentioned above.
Current state-of-the-art PaaS solutions, such as Cloud Foundry, OpenShift, and Apcera, are designed based on a monolithic architecture where dedicated components parts of the PaaS platform are responsible for managing deployed applications and providing PaaS functionality, e.g. scaling of an application. The nomenclature monolithic architecture refers to that underlying components of the platform are integrated with each other to form a core in which the underlying components are interwoven. Thus, the underlying components are not possible to separate.
There are several problems with such a design. For example, it is difficult to migrate an application and switch to another PaaS platform or provider. It is typically not supported, or at least not trivial, to setup a hybrid PaaS platforms, e.g. a federation of several PaaS providers. Sometime it can also be difficult to extend the PaaS platform with new functionality. It can also be hard to debug an application, as a new version of the application has to be uploaded to the PaaS in order to be tested.
While PaaS platforms offer easy-of-use and automation mechanism, it has recently become popular to build applications and web services using software containers. Docker, https://www.docker.com/whatisdocker/, is a popular technology used to build, ship and run any application as a lightweight container instead of using a virtual machine. A Docker container contains both the application and all its dependencies, which enables flexibility and portability making it easier to create distributed systems. Although software containers constitute a natural way to execute software on PaaS platforms, portability from one platform to a further platform normally requires adaption of the container to the further platform in order to use scaling and resilience function of the further platform.
As service-oriented architectures become more complex, a trend is to shift from monolithic architectures to so-called microservices architectures. Microservices make it possible to break down complex applications into small independent processes. In this way, it becomes possible to build highly decoupled systems, which consist of a large amount of microservices, each focusing on doing a relatively small task. Docker and software containers provide a way to isolate such processes and at the same time make it easy to develop and deploy new cloud services based on microservices.
Although microservices help simplify some problems with conventional PaaS platforms, e.g. making it easy to extend the application or scale separate parts of the application, the technology also introduces more complexity, and thus leaving more responsibility to the developers. To develop and use a distributed platform based on microservices as an alternative to a classical PaaS platform, it must be possible to easily locate and connect different components in the architecture with each other. For example, connecting a web server to a database without knowing where it will run in advance of deployment of the web server. This functionality is called service discovery and is a key component to implement a microservice based service-oriented architectures.
Service discovery can be implemented in many different ways where the easiest solution is to use static configurations, which will work for some cases, but which forces the service components to be deployed in a specific order. However, more advanced configuration methods such as service discovery becomes necessary as the architecture evolves and more services are added. In some cases, services might even be added on the fly and have a short lifetime, causing service locations to change dynamically.
Today many different solutions exist to solve the problem of dynamic service discovery, see for example SmartStack from Airbnb, http://nerds.airbnb.com/smartstack-service-discovery-cloud/. Normally, registering service locations to a registry server solves the problem of locating services. A client application can then query the registry server for information about the location of a certain service. One example of such discovery service is Netflix Eureka, https://github.com/Netflix/eureka, that consists of two applications; an Eureka client and an Eureka server. The Eureka server is a service registry where the Eureka client registers its services. The Eureka client is then embedded in the service source code. This means that the developer of the service source code must be aware of API for the Eureka client and the Eureka server.
Another example of using Airbnb's SmartStack is to set up a registry server to enable service discovery and registration. Apache Zookeeper is a centralized service for maintaining configuration information. SmartStack uses Zookeeper to handle service registration and a local proxy to route requests to available services. On top of Zookeeper and the proxy SmartStack has two processes called Nerve and Synapse to handle service registration and discovery. Nerve is responsible for registering services in Zookeeper and Synapse is responsible for re-configuring the locally running proxy with services registered in Zookeeper.
In order to create a microservice-based platform that is as easy to use as a conventional PaaS platform, developers should not have to care about service discovery, scaling or self-healing. Developers should just focusing on developing standard Docker containers, which can be tested and run on their local laptops like any other Docker container, and then deploy the containers to the platform. The platform will then automatically connect them together to a working application.
A problem is how to provide portability, without the need for services and components to be written in such way that they are aware of e.g. service discovery or health management mechanism and thus “talk the same language”. SmartStack separates the registration and discovery mechanism from the service by putting requirements on the execution platform to provide certain functions. Another problem with existing solutions is service outages whenever the service registry entity or other crucial nodes are not responding.